Conversation
| "type": "string" | ||
| }, | ||
| "edit_instructions": { | ||
| "type": "array", |
There was a problem hiding this comment.
I don't think this needs to be an Array? Object should be fine unless we're going to have multiple instructions (That aren't already being handled by the ffmpeg/requested arrays)
Without Array:
edit_request: { edit_instructions: { ffmpeg_instructions: [], requested_instructions:
[] } }
With Array:
edit_request: { edit_instructions: [ { ffmpeg_instructions: [], requested_instructions: [] } ] }
There was a problem hiding this comment.
I've been trying to work that out. I'm sure that we need an array, but I'm not sure at which level.
object of arrays: edit_request: { edit_instructions: { ffmpeg_instructions: [], requested_instructions: [] } }
or array of objects: edit_request: { edit_instructions: [ { ffmpeg_instructions: {}, requested_instructions: {} ] }
It depends on how ffmpeg works internally. I think I'll need to partially implement it and then run it against tests. It should be easy enough to change from one to the other if it doesn't work first time.
There was a problem hiding this comment.
I've been thinking some more
I think we should scrap ffmpeg_instructions altogether
IMO the JSON should only have the human-readable versions of the edit instruction, i.e.
"edit_instructions": [
{
"reason": "First edit",
"start_of_cut": "00:01:00",
"end_of_cut": "00:02:00"
}
]
Then we should translate that in the backend to ffmpeg instructions, but the ffmpeg instructions don't ever need to surface in the JSON
I'll push up a change to illustrate
Change description
Big refactor of edit request code.
Still to do